谷歌马甲包上架干货 | Google Play 机审解析与应对策略

如果您是Google Play审核团队App机审策略规则的制定者，让您去设计一套App机审系统，你会如何设计呢？

阿文从事出海行业多年，斗胆讲讲自己对Google Play App机审策略的理解，不足之处，还请大家多多海涵和不吝赐教。

先po一张思维导图，希望能在App机审策略规则方面给予各位一些启发，做好违规预防工作，而不是有了违规问题再去解决，从而使我们工作很被动。

源文件可私信小编获取，底部图片长按扫码添加！ 

正文来了

从我们提交aab文件到预审核通过，您的aab文件就进入GP审核系统开始排队了。Google审核系统会分析我们的aab文件，对代码和UI界面进行机器审核，尤其是对代码部分，而静态分析和动态分析为其审核重点，大多代码关联，恶意软件，代码违规都在这一阶段完成。所以，这一步也是我们顺利上架和版本更新迭代的重中之重。 

App代码机审

1

aab文件静态分析

(1)Hash值比对：在App防逆向工作中，通过对App全量文件提取Hash值，并遵循某种规则计算加密保存。然后在App运行时提取App文件，按照相同规则计算，将Hash值进行全量比对，来预防恶意程序纂改App。所以，猜测 Google大概率也会通过类似手段来初步计算我们App和其他违规App的文件相似度来作为账号关联的特征点。大家一定注意，如果一个文件只改名字是不会改变Hash值的！

(2)签名文件：使用同一个签名文件来签名不同的App万万不可，尤其使用之前违规的App签名。

(3)Manifest信息：Google会检测我们的Manifest内容（各种配置信息）是否合规。而且，对于马家堡而言，往往他们的Manifest文件会相当类似，这一点肯定会影响我们的审核。

(4)资源文件（Res，Assets）：资源文件内容是否违规，图片内容是否侵权，字符串内容是否符合App内容分级等等，Google都会审核。资源文件是否与违规 App 重复度过高也是审核的重点，比对方式可参考第一点。对于游戏产品而言，素材的审核会更严格。

(5)Dex文件：Dex文件节区信息和功能代码是机审的重点。想要理解Dex文件节区信息，必须要学习Dex文件格式的构成，可以简单理解为头文件(header)、索引区(xx_ids)、数据区(data)，有兴趣的自己可以查查。功能代码是代码审查的最关注点，代码是否和历史违规代码重复度过高，是否有恶意代码Google都会审查。

(6)SO文件：SO的理解也需要了解些逆向知识，SO（ELF）文件节区信息和导出函数猜测会是Google审核的方向。很多SDK都会将C++代码生成SO文件，所以对于SDK的选择就很重要，千万不要选择有风险的SDK用于我们的项目。

Google Play通过对App包文件进行一系列操作审查，最终得到一个多关键信息静态分析特征表，留做后续和Google后台违规数据库作对比。

2

运行时动态分析

静态分析完成后，会进入审核更为严格的动态分析阶段，Google Play可能会通过把我们的aab在沙箱（虚拟执行环境）中模拟执行，来全面分析我们的App。

(1) Java/Kotlin/Flutter/Compose Api调用链：不管我们用什么代码开发，都将运行在Java虚拟机上，都会转变为java字节码文件，Google会审查我们的Api调用链来确定我们是否使用了违规或者过时的Api，代码是否存在风险漏洞，也会审查我们与其他违规App的代码重复度。

(2) SO文件 C++代码 Api调用链：和Java Api同理，所以我们在开发中尽量使用自行开发的SDK，尽量不使用小公司SDK或者任何可能有风险的SDK，也强烈建议不要直接使用小的三方开源库，如果其代码不规范或者被其他的违规的App使用过，就非常有可能影响我们。

(3) Activity，Fragment堆栈（全路径）信息：界面实例信息都会存储在堆栈中，这一步重点检查我们和其他违规App的代码重复度问题，也是有可能导致关联问题的特征点。

(4) App创建的目录文件：这一点往往会被很多人忽视，尤其是在开发马家堡的过程中，App内部自行创建的目录文件名是非常容易被审查并产生关联的问题之一。

(5) 网络行为（与后端交互）：不仅仅App 代码本身，我们和后端的交互也是审查的重点之一，域名，Path路径，Json结构如果和违规App产品关联，也非常容易被处罚甚至被关联封号。

(6) 日志分析：细节决定成败，日志打印的节点，信息，检索Key也是非常容易忽视的点。如果两个不同包名的App，Google将日志打印开启后打印的Log非常相似，我想会很容易被认定为关联。 

Google Play在模拟运行App后，最终得到一个多关键信息动态分析特征表，留做后续和Google后台违规数据库作对比。 

UI界面

一句话总结，Google Play会在模拟运行App过程中，对每一个界面进行截图，然后与Google强大的后台违规数据库作对比，来确定您的App是不是和其他违规App相似，是否和违规App存在关联，界面元素是否侵犯产权等等。

敲黑板了

这么多复杂的特征点提取之后，静态分析特征表，动态分析特征表，UI界面会分别和Google强大的后台违规数据库作对比，检索您的App是否和违规App关联，是否是恶意软件，是否存在违规，最终输出一个阈值判断是否可以过审或者给予其他更严重的惩罚。

再次声明，以上均是本人对Google Play代码机审策略规则的一点点猜想， 不足之处，还请大家多多海涵和不吝赐教。Google真实的机审肯定无比庞大和严格，值得我们后续持续研究。

最后衷心地祝愿大家的App都能一次过审，业务开展顺风顺水。

公告区

腾讯在线文档链接如下或点击文末「阅读原文」：
https://docs.qq.com/sheet/DZldVTnBqeGxFRlBO?tab=BB08J2

GitHub链接如下：
https://github.com/AndroidGODev/Bad-Google-Play